第二十期技术雷达正式发布——给你有态度的技术解析！
技术雷达是ThoughtWorks每半年发布一期的技术趋势报告，它不仅是一份持续的技术成熟度评估，其产生还源于ThoughtWorks另一个更大宏大的使命—IT革命。我们一直深信，IT行业从定位、价值、实践和技术都会发生巨大的变革。然而任何宏观的变革，都会有一些微小的信号，我们需要持续关注这些微小的改变，这也就是技术雷达的由来。
技术雷达自2010年创办以来，已经走过十年、累计发布二十期。它比那些我们能在市面上见到的其他技术行情和预测报告更加具体、更具可操作性，因为它不仅涉及到新技术大趋势，更有细致到类库和工具的推荐和评论，因此更容易落地。经过半年的追踪与沉淀，ThoughtWorks TAB（ThoughtWorks技术咨询委员会）根据我们在多个行业中的实践案例，为技术者产出了第20期技术雷达，对百余个技术条目进行分析，阐述它们目前的成熟度，并提供了相应的技术选型建议。
日新月异的数据形态
十年前，数据几乎等同于关系数据库。如今，数据则可能呈现出各种形态，包括NoSQL、时间序列、像CockRoachDB和Spanner这样提供全局一致性的SQL存储，以及提供聚合日志文件查询功能的事件流。随着数据源不断增长，数据规模越来越大，种类越来越多，变化速度越来越快，企业想要对这些数据做出更实时的响应，上述情况也就应运而生了。对于开发人员，每种形式的数据使用方法都存在固有的优缺点，如何取舍是个难题。架构师和开发人员应该密切关注各种工具和模型提供的新功能，同时保持勤奋好学，不要完全以对待现有工具的常用方法来使用新工具。我们必须认识到数据形势正在发生重大变革，并坚持寻找合适的策略和工具。
Terraform生态系统建设
开发人员喜欢抽象层，原因很明显，因为他们可以将复杂问题封装到抽象层中，从而集中精力处理更高层级的问题。在前几期的技术雷达中，我们都阐述了这种发展趋势，很多团队在同时使用云和容器时都会采用这种方法。一开始他们关注的是Docker及其生态系统。然后焦点开始转向Kubernetes。现在，我们发现主要活动总体上都集中在基础设施即代码方面，尤其是集中在Terraform生态系统上。虽然除了Terraform，我们还推荐了其他工具，但是它在提供商社区中的采用率仍然让人印象深刻。本期雷达的内容重点包括Terratest（用于测试基础设施代码），以及GoCD的新提供商（可以使用Terraform配置GoCD）。
Kotlin方兴未艾
Kotlin作为一项开源语言，不仅在Android环境中获得了广泛应用，而且还在向其他环境拓展，也在技术雷达中受到了持续密切的关注。由于不喜欢现有的语言选择，JetBrains在内部开发了Kotlin，并随后开源。Kotlin似乎在各种开发人员中广受欢迎。它经常在各种平台和工具中用作通用甚至专用开发语言，而且在技术雷达中出现的频率也越来越高。此外，我们的项目团队也在采用该语言（Ktor、MockK、Detekt、HTTP4K）。这个新兴语言在实用性设计和先进工具中获得了广泛应用，并且形成了一个蓬勃发展的生态系统，取得了巨大的成功，对此我们深感欣慰。
封装边界的泄漏
随着“一切即代码”理念的盛行，以前难以改变的绝大多数环节（基础设施、安全、合规性和运营），几乎都变得可以通过编程来处理，这就意味着开发人员可以采用更完善的工程实践。然而，我们仍然经常看到，要么配置子系统异常复杂，要么过度依赖于可视化编排工具，逻辑渗透到配置文件中，以YAML编写的条件语法晦涩复杂，还有各种技术需要使用大量编排框架等情况。随着多语言编程、基础设施即代码和一切皆服务技术的出现，我们不再需要将各种组件都组合到单一内聚的系统中。因此，原本应位于系统边界内的逻辑就会泄漏到编排工具、配置文件和其他管道中。虽然有时候确有这种必要，但是我们建议各团队保持谨慎，考虑将此类代码放在开发人员执行测试、版本控制、持续集成和其他完善的工程实践的位置。请避免将业务逻辑放在配置文件中（并且避免使用要求将业务逻辑放在配置文件中的工具），尽可能减少必须执行的编排操作，不要让编排功能主导你的系统。
技术
Four key metrics
详尽的DevOps现状报告侧重于对高绩效组织的数据驱动型统计分析。这项研究持续多年，结果发表在Accelerate，证明了组织绩效和软件交付效能之间存在直接关联。研究人员证实，只需四个关键指标就能区分低绩效、中绩效和高绩效人员：前置时间、部署频率、平均修复时间 (MTTR) 和变更失败率。的确，我们已经发现这四个关键指标（Four key metrics）是个简单却强大的工具，可帮助领导和团队专注于衡量并改进重要的环节。实施构建流水线是一个良好开端，以便你能够捕获四个关键指标，并使软件交付价值流可见。例如，作为 GoCD Analytics的一等公民，GoCD流水线能够衡量这四个关键指标。
Continuous delivery for machine learning (CD4ML) models
机器学习的持续交付 (CD4ML) 模型（Continuous delivery for machine learning -CD4ML models），将持续交付实践应用于开发机器学习模型上，以便于随时应用在生产环境中。该方法解决了传统机器学习模型开发的两个主要问题：一个是训练模型和将模型部署到生产环境之间的周期过长，此过程通常包括将模型手动转换为可上线的代码；另一个问题是使用被过时数据训练过的产品环境模型。
机器学习模型的持续交付流水线有两个触发因素：(1) 模型结构的变动；(2) 训练与测试数据集的变动。要使其发挥作用，我们需要对数据集和模型源代码进行版本化。流水线通常包括用测试数据集来测试模型、按需使用H2O等工具来对模型作自动转换、以及将模型部署到生产环境以交付价值。
Ethical OS
作为ThoughtWorks的开发人员，我们对于工作中可能涉及到的道德问题十分敏感。随着社会对科技的依赖程度日益增长，软件开发团队在制定决策时必须考虑道德问题。目前已经出现的一些工具，可以帮助我们思考自己所构建的软件会在未来产生什么影响。此类工具包括技术塔罗牌和道德风险手册（Ethical OS），这两类工具都获得了广泛好评。道德风险手册为我们提供了一个思维框架和一系列工具，可以促进我们围绕软件构建方面存在的道德问题展开讨论。该手册由Institute of the Future（未来研究所）和科技与社会解决方案实验室（Tech and Society Solutions Lab）联合编制。其中探讨了一系列切实的风险，例如网瘾、多巴胺经济，而且还分析了很多值得探讨的场景。
Smart contracts
我们在使用分布式账本技术(DLTs)方面积累的经验越多，遇到的当前智能合约（Smart contracts ）未完善之处就越多。从理论上来看，在账本上自动添加不可否认、不可逆的合约是个好主意。但如果在你考虑如何使用现代化软件交付技术来开发它们，以及出现实施方式之间的差异时，问题就出现了。不可变数据是一回事，但不可变业务逻辑则完全是另外一回事！一定要想清楚是否在智能合约中包含逻辑，这一点真的非常重要。我们已经发现，不同的实施方式之间存在截然不同的运营特征。例如，即使合约可以演变，不同平台对这种演变的支持程度也不一样。我们的建议是，在智能合约中加入业务逻辑之前，请认真考虑，并权衡不同平台的利弊。
Release train
我们已亲眼见证，组织通过使用版本火车（Release train）概念，从极低的发布频率成功转向更高频率。版本火车是一种用于协调跨多个团队或具有运行时依赖性组件的发布技术。无论所有预期功能是否已准备就绪，所有版本根据一个固定且可靠的时间表发布（火车不会等你，如果错过，就只能等下一趟了）。虽然我们完全支持关于定期发布和演示可用软件的纪律性，但从中长期来看，我们发现该方法存在一些严重缺陷，因为该方法会增加有关变更排序的临时耦合，而且如果团队赶着在给定时间范围内完工，质量可能会降低。我们更倾向于关注在必要的架构与组织的方法，来支持独立发布。虽然火车对于提升较慢团队的速度非常有用，但我们也看到它给快速团队带来了上限。所以我们认为，在使用该技术时，应尽量小心谨慎。
平台
EVM beyond Ethereum
以太坊虚拟机(EVM)最初是为以太坊主网络设计的。但如今，大多数团队不再想要从头开始发明区块链；相反，他们会选择“超越以太坊的EVM（EVM beyond Ethereum ）”。我们看到众多区块链团队选择对以太坊进行分支（如Quorum）或实现EVM规范（如Burrow、Pantheon），并添加他们自己的设计。这样做不仅是为了重用以太坊的设计，还可以利用其生态系统和开发人员社区。对于许多开发人员而言，“智能合约”的概念差不多等同于“以Solidity编写智能合约”。虽然以太坊本身具有一些限制，但围绕EVM生态系统的技术正在繁荣发展。
InfluxDB
时序数据库（TSDB）已经问世一段时间了。随着符合时序模型的使用场景愈发常见，TSDB日益成为主流。InfluxDB仍然是TSDB的理想选择，主要用于监控场景。TICK Stack就是一款以InfluxDB作为核心的监控解决方案。Influx 2.0的alpha版最近引入了Flux（一种用于查询和处理时序数据的脚本语言）。虽然Flux目前仍处于早期阶段，且无法断定能比InfluxDB获得更广泛的应用，但它承诺会比InfluxQL更强大且更具表达力，且能将时序分析工作交由数据库来完成。然而，InfluxDB只有企业版才能提供集群支持，因此在项目中需要留意这个限制。
Istio
Istio正逐渐成为将微服务生态系统付诸应用的标准基础设施。其开箱即用的横切关注点的实现，已经帮助我们快速实现了微服务。这些横切关注点实现包括：服务发现、服务之间和从请求到服务之间的安全性、可观测性（包括遥测和分布式跟踪）、滚动发布和弹性。Istio是我们一直使用的服务网格技术的主要实现平台。我们非常享受它的每月发布及无缝升级所带来的持续改进。我们使用Istio来启动项目，从一开始就能获得可观测性（跟踪和遥测）和服务之间的安全性。我们正密切关注其在网格内外各处服务之间身份验证方面所做的改进。此外，我们希望看到Istio为配置文件建立最佳实践，从而在为服务开发人员提供自主权和为服务网格运营商提供控制权之间达到平衡。
Hot Chocolate
GraphQL生态系统和社区正不断发展。Hot Chocolate是用于.NET（包括新的core和原先的传统框架）的GraphQL服务器。该平台可用于构建和托管schema，并能用于处理针对这些schema的查询。Hot Chocolate的开发团队近期增添了schema拼接功能，允许从单个入口点跨多个schema（从不同位置聚合而成）进行查询。虽然该功能会被以多种方式误用，但还是值得对其进行评估。
Knative
无服务器架构的应用，让FaaS编程风格在开发人员之间越来越普及。该架构通过独立构建和部署的函数，帮助开发人员专注于解决核心业务问题。这些函数能响应事件、运行业务流程、在流程中生成其他事件，完成任务后随即消失，不再消耗资源。以前，AWS Lambda或Microsoft Azure Functions等专有无服务器平台已实现这种编程范式。Knative是基于Kubernetes的开源平台，用来运行FaaS工作负载。Knative有几点突出之处：开源且适用于任何供应商；实现了CNCF无服务器工作小组白皮书中所定义的无服务器工作流；通过实现符合CNCF CloudEvents规格的事件接口，来确保跨服务的互操作性；尤其重要的是，它能够解决在运维混合FaaS与长期运行的容器化架构时所遇到的常见挑战。该平台易与Istio和Kubernetes集成。例如，通过在不同版本的函数之间切换流量，开发人员可以利用Istio实施金丝雀发布策略。对于处在相同Kubernetes环境中的长期运行的容器服务和FaaS程序，开发人员都可以享受到Istio所提供的可观测能力。我们预计，Knative开源事件接口将继续支持更多底层源和目的事件的集成。
工具
UI dev environments
随着越来越多的团队拥抱DesignOps，该领域的实践和工具也日渐成熟。UI开发环境专注于用户体验设计师与开发人员之间的协作（UI dev environments），为UI组件的快速迭代提供了综合环境。目前在该领域可用的工具包括：Storybook、React Styleguidist、Compositor和MDX。这些工具既可以在组件库或设计系统的开发过程中单独使用，也可以将其嵌入到web应用程序中使用。通过使用这些工具，许多团队在开发准备工作中缩短了UI反馈周期并改善了UI工作的时间。于是，使用UI开发环境成为了我们合理的默认选择。
batect
大量的精力仍然被浪费在部署本地开发环境和排查“works on my machine”（在我的机器上可以工作）的问题上。多年来，我们的团队已经采用“检查并实施”的方法，使用脚本化方法来确保本地开发环境的配置始终一致。batect是由ThoughtWorker开发的一款开源工具，可帮助轻松搭建和共享基于Docker的构建环境。batect作为构建系统的入口点脚本，能够启动容器来执行完全不依赖于本地配置的构建任务。对构建配置和依赖项的更改仅通过源码管理即可共享，无需在本地机器或CI代理上进行任何更改或安装。在该领域的其他工具中，我们偏向于使用Cage，但我们也看到batect正在以符合我们团队需求的方向迅速发展。
Detekt
Detekt是一个适用于Kotlin的静态代码分析工具。它能够发现代码中的坏味道和复杂性。你可以通过命令行运行它，也可以使用其插件集成一些热门的开发者工具，例如Gradle（用于在项目构建时执行代码分析）、SonarQube（用于除静态代码分析外的代码覆盖率统计）和IntelliJ等。Detekt能够给Kotlin应用的构建流水线锦上添花。
Humio
在日志管理领域，Humio是一款相对较新的工具。该工具完全从零开始构建，通过基于定制设计的时序数据库的内置查询语言，在日志提取和查询方面性能非常快。从提取、可视化和报警提醒的角度来看，该工具能够与几乎所有工具相集成。日志管理领域已被 Splunk 和 ELK Stack主导，所以，有替代选择也是一件好事。我们将持续关注 Humio 的发展。
Kubernetes Operators
我们对于Kubernetes对行业产生的影响兴奋不已，但也担心随之而来的运维复杂度。保持Kubernetes集群启动并运行、管理在该集群上部署的软件包都需要特殊技能和时间。升级、迁移、备份等运维流程经常会是一项全职工作。我们认为Kubernetes Operator会对降低复杂度起到关键作用。该框架提供了一套标准机制，为在Kubernetes集群中运行的软件包描述了自动化运维流程。虽然Operator由RedHat发起和推广，但多个社区为常用开源软件包（如Jaeger、MongoDB和Redis）开发的Operator已初露头角。
语言&框架
Apache Beam
Apache Beam是一个开源的统一编程模型，用于定义和执行数据并行处理流水线的批处理与流式传输。Beam模型基于数据流模型，允许我们以优雅的方式表达逻辑，以便在批处理、窗口化批处理或流式传输之间轻松切换。大数据处理生态系统已经取得了长足发展，这可能会导致人们难以选择正确的数据处理引擎。允许我们在不同运行程序之间切换，这是选择Beam的一个关键原因。几个月前，它支持了Apache Samza，这是除Apache Spark、Apache Flink和Google Cloud Dataflow之外的又一个新的运行程序。不同运行程序具有不同能力，且提供轻便的API是一项困难的任务。Beam将这些运行程序的创新主动应用于Beam模型，并与社区合作以影响这些运行程序的路线图，从而试图达到微妙的平衡。Beam具有包括Java、Python和Golang多种语言的SDK。我们也成功使用了Scio，它为Beam提供了Scala包装器。
Puppeteer
与Cypress和TestCafe一样，Puppeteer也是备受我们团队推崇的一款Web UI测试工具。Puppeteer能够对无头浏览器进行细粒度控制，生成时间轴信息，以用于性能诊断等。我们的团队发现，相较其他基于WebDriver的同类工具，Puppeteer更加稳定、快速和灵活。
Room
Room是一个数据持久化库，用于在Android上访问SQLite。它支持使用最小限度的样板代码进行数据库访问，同时通过编译时SQL校验使数据库访问更加稳健。令我们开发人员感到满意的是，使用LiveData后，Room能够与可观察查询完整集成。Room是Android Jetpack组件之一，旨在简化Android应用开发。
Rust
Rust最近一次在技术雷达中出现是2015年，自那以来，我们看到开发者对Rust的兴趣在逐渐提升。我们的一些客户正在使用Rust语言，尤其在围绕基础设施工具方面的使用最为常见，而在高性能的嵌入式设备中也可以见到Rust的身影。不断完善的生态系统以及语言本身的改进推动了人们的兴趣提升。语言的改进方面，包括了直接的性能增强，也包括了直观表现力的提高，例如非词法作用域的更改。大多数重大变化都包含在去年12月发布的Rust 2018标准中。
fastai
fastai是一个开源Python库，能够简化对快速且准确的神经网络的训练。它基于PyTorch构建，已成为备受我们数据科学家欢迎的工具。fastai可简化模型训练中的难点，如预处理、使用少量代码加载数据。该库根据深度学习最佳实践构建而成，对计算机视觉、自然语言处理(NLP)等提供开箱即用的支持。创始人的动机是为深度学习创建易于使用的库，使之成为一个改进版的Keras。GCP、AWS和Azure很快便接纳了fastai，将其包含在机器学习的镜像中。fastai的创建者意识到Python在速度和安全方面的限制，已宣布接纳Swift作为深度学习的替代语言。我们将密切关注其进展。
以上是我们在最新一卷技术雷达中随机摘取的几个Blip，欲获取整版技术雷达，请点击左下角[阅读原文]进行下载！
5月9日，ThoughtWorks技术委员会成员、中国区区块链实践负责人刘尚奇还将在线上为大家带来新一期雷达解读，细述四大主题趋势，解析重点技术条目，席位有限，欢迎扫码参与～
- 相关阅读 -
文中相关外部链接可至洞见网站查看。
本文版权属ThoughtWorks公司所有，如需转载请在后台留言联系。